Sounds good. I think creating the branch is ok thought if it doesn't prove to be viable to merged back into the core code or no one is actively maintaining it after 4 months I'd like to have the option to remove it to ensure we keep things clearly delineated as to what is the 'correct' 2.4 patches branch.
-Eric Andrew Petro wrote: > Eric, > > The branch would be ad-hoc -- for the specific purpose of exploring > ALM maintenance against uPortal 2.4.2, and not for other general fixes. > > I expect it would be temporary in that over time people will care > about ALM maintenance less and less, having moved on to DLM and bigger > and better things. > > I'm not volunteering to merge this code into the real ongoing > 2-4-patches branch. I'd be open to doing that work if it proves > desirable. Presently I'm looking to do the "simplest thing that could > possibly work" to do uPortal 2.4.2 ALM triage in an open way. > > Downsides of patching up the existing 2-4-patches branch include: > having to patch up this deployment to latest 2-4-patches or having to > deal with unrelated differences since 2.4.2. Presumably valuable but > not the present project. The ALM-specific exploratory branch is not > guaranteed to be backwards compatible and countenances more daring > changes. Its purpose is different from that of 2-4-patches. > > Andrew > >> Would this branch be temporary and eventually the code is merged into >> the 'real' 2.4 and 2.5 branches or would this stick around for a >> while? What are the downsides of just patching up the existing 2.4 >> branch? >> >> -Eriuc >> >> Andrew Petro wrote: >> >>> uPortal developers, >>> >>> A client [1] has been generous enough to throw me a few [2] hours to >>> work on ALM diagnostics, error detection, and bugfixing, with an >>> especial need to apply these changes to 2.4.2. I'd like to create a >>> "2-4-2-alm-maint" exploratory branch for the purpose of sharing this >>> maintenance code. I hope this will be of interest and use to fewer >>> and fewer uPortals as folks migrate to DLM, but since this is >>> maintenance of uPortal itself it seems to me to belong in uPortal >>> source control. >>> >>> Andrew >>> >>> >>> >>> [1]: I dislike that cloak and dagger "some client, somewhere" >>> allusion probably even more than you do, and I'll see about giving >>> credit where credit is due on any fruits of this labor. More >>> openness is better. Unfortunately, it's not always clear how much >>> it is acceptable to share when. >>> >>> [2]: Don't expect the realization of all ALM hopes and dreams ever >>> had out of this effort -- it's a very few hours involved. However, >>> with a maintenance branch to explore mitigating issues in ALM in >>> older uPortal environments, there's a place for continued >>> collaboration on this if desired. >>> >>> > >
smime.p7s
Description: S/MIME Cryptographic Signature
