[sakai2-tcc] 2.9.1-all tag available

Fri Feb 15 16:24:37 PST 2013

On Jenkins you can have tools build the dependent projects, but you can't
set that up at all to release, or have it work with the Jenkins release
plugin in any way that I've seen.

There was also some kind of neverending loop somewhere where it couldn't
figure out the dependency cycle and it would build one project, trigger
another while would trigger the first and have the server building forever,
so I had to turn off the feature to trigger builds like that. It might have
been a bug that was fixed, or maybe there was some bug in that Sakai tool.
It also caused a huge problem during the release because the poms were
changed so it would see something is changed, and build that, and trigger
off all of the dependencies so end up getting the server building for like
12 hours. I think that we just have way too many tools, too many poms and
dependencies that are incorrect.

Obviously if it didn't have tool X depend on tool Y's impl and service
(just the api's) then it would realize it didn't need to rebuild it as
often (or at all). But we don't have it setup like that, and for the
SNAPSHOT's that's maybe not possible unless we set lots of things to not be
SNAPSHOTS?

You really think that someone should be using the 2.9.1-all tag or any
tag's there-in? Which group of users?

Developers should ideally be developing on trunk so they can get their
patches back in. If their school is on 2.9 they should be testing them on
2.9.x so they can get them into the next version of 2.9. It doesn't do the
community any good to have them working on 2.9.1.

Deployers should just be using the binary .tar.gz as-is and not modifying
it. If they do need to modify it modify it, they'll need to set a custom
version anyway, and they'll probably want it off the .x branch so they can
more easily pull in the latest updates when we merge fixes. Otherwise
they'll be doing a lot more of their own branch management.

Perhaps it has some value to some SCA like rSmart or iRubric that wants to
take this static version, apply just *their* patches and release it as-is
(or reversion everything and release it like rSmart does with their crazy
2.8.9 version or whatever they're on)

Anyway, what I would do for (say the 2.9.2 or at least the RC's which I
didn't do for the 2.9.1 rc's) is make the externals and put in the revision
flags.
For instance . . .

kernel		-r118058	https://source.sakaiproject.org/svn/kernel/branches/kernel-1.3.x

. . . etc

I believe that the way we (you?) set up the parents with the relativePath,
it means it will check for local modifications before going out to look for
newer stuff in the repository. If not I'll just locally change the versions
of everything using the versions plugin or an xslt. Something to think
about anyway. . . This should give everyone what they want, as long as
nobody is actually using assemblies. ;) (I don't know if we ask that
question)

On Fri, Feb 15, 2013 at 4:49 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> The built Apis for all tools are already released to the repository as
> part of the release process. So that takes care of the first and third
> point.
>
> The other one is Jenkins but that probably not as huge an issue as you
> think, as you can have tools built their dependent projects, so yeah it
> will build extra but not all.
>
> I am starting to see less value in the indies as well, especially now that
> tool development  has slowed right down. I don't think we should do
> anything to remove the indie nature( ie their assembly etc) just yet, but
> moving back to full source checkouts is probably what we need to do in the
> short term.
>
> I disagree that the all tag isn't useful, a lot of people want to use it.
> And they probably base custom builds from it, so it's more of a convenience
> than anything.
>
> I do take copies of tags into msub and modify them with the same version
> number so that I don't have to adjust other projects, and there is nothing
> wrong with that.
>
> Cheers
> Steve
>
> Gesendent von meinem iPhone
>
> On 16/02/2013, at 5:21, Matthew Jones <matthew at longsight.com> wrote:
>
> Thanks for bringing this up Chuck,
>
> After releasing 2.9 11 times since b03, I've been increasingly unhappy
> with it. Though I'm not sure if serious disruptions are better for a minor
> release (2.9.2) or waiting until the next big one (2.10, or possibly 3.0
> [or 4.0 if we say 3.0 was an unfinished experiment]) It's not super
> difficult anymore, but there's a lot that can go wrong, and the things that
> can go wrong may not be obvious for weeks or months later, causing a lot of
> lost developer time, something we have limited amounts of. I believe that
> the bundling up the released indies into this release adds no value to
> developers, deployers, basically anybody. I can't see any audience that
> really gains from this knowing what they're getting besides maybe upper
> management who think that static compiling from tagged releases on static
> numbers provide some kind of assurance over failures? Anytime you compile
> something with maven the artifacts will be new, different and
> unpredictable.
>
> The static numbered tags are meant to not be changed, yet people will
> download this 2.9.1-all, add local patches and re-compile and use their own
> versions. (Often without changing the versions) This is what the SNAPSHOT
> is for, active development and modification. The maven versions plugin
> helps with a lot of this as well with the *versions:lock-snapshots *and
> other pseudo-release goals.
>
> Here's the value I see out of the *indies*
> - The API's from all of the indies are useful to have released in the
> repository.
>   - Released API's mean that Jenkins can build an indie as soon as it's
> modified and notify individual committers as soon as something breaks.
> Otherwise it would have to build everything (which can take up to an hour)
> and not often know what change broke the build.
>   - Released API's also mean that contrib projects that use Sakai services
> can build without having to build the entire core. You can just download
> the contrib projects and mvn install sakai:deploy. This is pretty great.
>
> - There is little value from the assemblies and core-deploy
>   - You can't use a new assembly in an older version (For example a 2.9
> assembly in 2.8). This was tried recently with Sitestats and because
> FormattedText changed in kernel-util in 2.9 it failed when deployed into a
> 2.8 instance. So you'd have to recompile a new sitestats for 2.8 and for
> 2.9 if you want the newer sitestats, not just use the deploy (Or just
> provide a sitestats bound against an old version of Sakai, which might also
> work)
>   - To actually use core-deploy and deploy something you need maven and
> often java anyway, so you don't save anything other than downloading the
> source. Often the source can be smaller than the binary anyway, not really
> saving much on bandwidth costs
>   - This increases the time for the buildled these are bundled up, even if
> they're really not even used.
>
> So here's what I think could happen or 2.9.2, but it would require some
> work.
>
> - Figure out a way to just release all of the API's. Either as a profile
> hack in maven or as a file system hack with symlinks. (Haven't figured this
> out yet)
>   - This isn't even a huge deal if API's don't change after 2.9.1, since
> all of the 2.9.1 one's are already released.
> - Get rid of core-deploy (is not in the -all build anyway) and also get
> rid of the assemblies (because they're not needed)
> - Don't release anything independent, release everything together as a
> monolithic release (Skip the release plugin)
>   - To do this properly, master (which references api dependencies) would
> need to point to the 2.9.1 versions of the apis, and all of the indies
> would have to have their versions updated to *something*. Perhaps the
> versions plugin could lock down these versions. What it's called doesn't
> seem relevant as this version is mostly for QA purposes anyway and we can
> just map it internally (for instance it would probably be something like
> 2.9-20131117.213112-16). Maybe the maven versions plugin could still be
> used to update and not commit as well.
>
> This is all what people seem to want anyway?
>
>
>
> On Fri, Feb 15, 2013 at 8:28 AM, Charles Severance <csev at umich.edu> wrote:
>
>> Thanks from all of us :)
>>
>> Hey (this is to everyone) - is there *any* reason not to make the 2.9.2
>> tag - just the "all" variant and then also make a "2.9.2-partia" if folks
>> really want a subset of the code when they check out?
>>
>> We might as well gently trend in that direction IMHO.
>>
>> Just thinking out loud - feel free to disagree.
>>
>> /Chuck
>>
>> On Feb 15, 2013, at 8:24 AM, Steve Swinsburg wrote:
>>
>> > Hi all,
>> >
>> > As discussed, I've created a 2.9.1-all tag:
>> > https://source.sakaiproject.org/svn/sakai/tags/sakai-2.9.1-all/
>> >
>> > Work tracked here for future reference:
>> > https://jira.sakaiproject.org/browse/SAK-23234
>> >
>> > I'll ping the dev list in a sec to respond to the other thread.
>> >
>> > cheers,
>> > Steve
>> >
>> > _______________________________________________
>> > sakai2-tcc mailing list
>> > sakai2-tcc at collab.sakaiproject.org
>> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130215/af4873aa/attachment-0001.html 